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(54) Method of monitoring the operation of a computer 

(57) A method is provided for automatically storing 
indications regarding conditions prevailing in a compu- 
ter running a user application (1) that employs a library 
(2). This method involves providing an interface compo- 
nent (3) interposed between the user application and 
library. The interface component (3) is arranged to 
receive messages from the user application (1) des- 
tined for the library (2), pass on these messages to the 
library (2), and monitor and store indications regarding 
conditions prevailing in the computer at the time the 
messages are received or passed. In a preferred 
embodiment provision is made for dynamically chang- 
ing the indications to be monitored. 
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Description 

Held of the Invention 

The invention relates to a method for automatically storing indications regarding conditions prevailing in a computer 
running interacting programs such as abuser application employing a library program. 

Background of the Invention 

A computer or data processing machine is a machine that is able to execute a series of instructions or steps so as 
to perform some predetermined functions. This series of instructions or steps is usually called a program or application. 

As applications of increasing complexity are developed, it has become the practice to combine together programs 
to produce the required functionality. Figure 1 of the accompanying drawings illustrates a simple example where two 
programs 1 and 2 interact, this interaction being represented schematically by the complementary shapes of the pro- 
grams 1 and 2. Program 2 is typically a library program comprising a number of routines for executing standard func- 
tions, whilst program 1 may be a user application making use of at least some of the library routines. 

By way of example, program 2 may be a print library ?R.a" in binary form including, in particular, a routine PRINT 
As illustrated in Figure 2, binary print library TR.a" is derived from a source code version "printc" of the print library by 
compilation (step 10). In accordance with standard practice, "print.c" will generally include a reference to a header file 
"print.h M containing the function prototypes for the routines contained in the print library; in compiling "printc", the com- 
piler will make use of the information in the header file. 

The print library will frequently only be distributed in its binary form "PR.a" together with the associated header file 
"printh". 

To use the PRINT routine in the library, the source code of a user application 1 , such as "main.c" includes a refer- 
ence to the library header file "print-h". On the program "main.c" being compiled (step 11), the information in the header 
file is used by the compiler in producing the binary file "object" of the user application. Of course, before the user appli- 
cation can be run, it must be linked (step 12) to the binary form of the print library to produce an executable program 
"execuT. Now when the program "execuT is run, a call for the routine PRINT results in the corresponding code in the 
print library being executed. 

A problem that frequently arises with complex applications is to understand the interaction between the different 
constituent programs, so as to check the correct operation of the computer and of each of the programs when they are 
run by the computer. This problem is notably encountered when applications are being debugged or tested and is made 
more difficult by the fact that the source code of library programs is frequently not available. Another problem is to trace 
or determine particular parameters of the computer running the application, at the time functions calls are made 
between different parts of the application, that is to determine the conditions prevailing in a computer running the appli- 
cations. Such parameters could include the free memory area, or the number and type of available resources, or other 
technical features of the computer. 

It is an object of the present invention to provide a monitoring method useful in solving the above problems. 

Summary o f the Invention 

According to the present invention, there is provided a method of automatically storing indications regarding con- 
ditions prevailing in a computer running a first program that makes use of a second program, said method involving car- 
rying out the following steps using an interface component: 

- receiving from the first program messages destined for the second program, 

- passing said messages to the second program, and 

-- monitoring and storing indications regarding conditions prevailing in the computer at the time the messages are 
received or passed. 

The invention is useful for tracing the interaction between programs, and helps in testing and/or debugging. The 
invention may also be used for tuning programs to the computer, that is, adapting programs to a specific technical envi- 
ronment. Furthermore, the invention allows for real time monitoring of computer parameters during the operation of the 
computer running the programs. It is notably useful for telecommunications applications or for other such types of appli- 
cations that require high reliability; indeed, in situ monitoring helps in detecting, preventing or repairing malfunctions. 

The invention may also be used for distributed applications, or for multiprocessor applications. In this cases, it will 
provide a valuable tool for checking the operation of the applications. 

In a preferred embodiment, a control program is provided to dynamically change the type or nature of the indica- 
tions to be monitored and stored. Advantageously, the control program operates by setting a parameter in a memory 
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area accessible to said interface component; the interface component then accesses this parameter each time it 
receives/passes a message between the first and second program, and determines the indications to be monitored and 
stored in dependence on the value of said parameter. 

s Brief Description of the Drawings 

A method embodying the invention for monitoring the interaction between two programs will now be described, by 
way of non-limiting example, with reference to the accompanying diagrammatic drawings, in which: 

is a schematic view of the interaction of two programs, as practised in the prior art. 
is a diagrammatic illustration of the compiling and linking steps involved in producing an implementation 
of the Figure 1 arrangement; 

is a schematic view similar to Figure 1 , showing the interposition of a monitoring component between the 
two programs in accordance with the invention; 

is a diagram illustrating the operation of an implementation of the Figure 3 arrangement; and 
is a diagrammatic illustration of the compiling and linking steps involved in producing the Figure 4 imple- 
mentation of the Figure 3 arrangement. 



10 . Figure 1 
. Figure 2 

. Figure 3 

is . Figure 4 
. Figure 5 



Best Mode of Carrying Out the Invention. 

20 

Figure 3 is a schematic view similar to Figure 1 showing two interacting programs 1 and 2; in accordance with the 
invention, in Figure 3 an interface component 3 is operatively interposed between programs 1 and 2 . This component 
3 is arranged to receive any message or call - such as commands or requests - issued by the first program 1 , and nor- 
mally destinated for the second program 2; the interface component 3 then passes on the messages to the second pro- 

25 gram 2 and in due course returns the response issued by the second program back to the first program. Thus, interface 
component 3 hides the second program 2 from the first program 1, and the interface component 3 will behave with 
respect to first program 1 as if it were the second program 2; at the same time, the operation of the second program 2 
will be the same as in the prior art arrangement of Figure 1 . The presence of component 3 is thus effectively transparent 
to both the first and second programs. 

30 The interface component 3 is also arranged to monitor computer parameters, and/or trace messages coming from 
first program 1. 

The operation of the first and second programs 1 , 2 of Figure 3 will thus be exactly the same as the operation of 
the first and second programs 1 and 2 in the prior art arrangement of Figure 1 . However, the invention provides moni- 
toring of the interaction between the programs and/or of the parameters of the computer. 
35 In a preferred embodiment, the invention can be applied to the monitoring of the interaction of a user application 
with a library - hereafter called the original library. To this end, there is provided a bridge library that comprises for each 
routine of the original library, bridge code that allows the corresponding routine of the original library to be used, but 
hides its name. 

There is also provided a spy library, that comprises for each routine of the original library, spy code that presents 
40 the same name as the corresponding routine of the original library and, by calling that routine through the bridge library, 
makes the same functionality available. Thus any user application may be linked to spy code, just as if it were a routine 
of the original library. 

The bridge and spy libraries together make up the interface component 3 of Figure 3. 

In a preferred embodiment of the invention, the bridge or spy library is provided with means for dynamic or selective 
45 tracing or monitoring, in which the depth of monitoring or tracing can be controlled. This helps in adapting the level of 
monitoring or tracing to the needs of a user. 

By way of example, an implementation will now be described of the interface component 3 for interposition between 
the user application binary "object" and library binary "PR.a" of Figure 2 in relation to the library routine PRINT. 

In this implementation, the interface component 3 comprises a bridge library binary "bprinto" and a spy library 
so binary "sprinto". As illustrated in Figure 4, the binary "sprinto" is arranged to respond to a call PRINT issued by the 
user program binary "object" by issuing a call BPRINT which is picked up by the bridge library binary "bprinto" and 
passed on as a "PRINT call to the original print library "PR.a", causing the routine PRINT to execute. The PRINT call 
r issued by the user program "object" is hidden from the original library "PR.a" by the manner in which the libraries "PR.a" 

and "bprirrto" are linked ( this 'hiding' being implemented by a standard command available with most modem com- 
55 piler/linker programs); the hiding of library "PR.a" by library "bprinto" is depicted in Figure 4 by the shape of the 
"bprinto" component. 

The spy library "sprinto" also includes code for monitoring and tracing, the level of this monitoring being modifiable 
through a 'scope' program that uses a memory area shared with sprint.o to pass the latter parameters for controlling its 
monitoring level. Upon the spy library receiving a call from the user program, it checks these parameters, implements 
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the monitoring/tracing to the level required, and then passes on the call, in appropriate form, to the bridge library. 

Figure 5 illustrates the various program files and compiling and linking operations involved in implementing the 
above example. The original library binary "PR.a" and user program binary "object" are produced as already described 
with respect to Figure 2, The bridge library binary "bprinto" is produced by compiling (step 14) a bridge library source 
file "bprintc", this latter including references to header files "print.h" and "bprinth". The spy library binary "sprint.0" is 
produced by compiling (step 15) a spy library source file "sprintc", this latter including references to header files 
"printh" and "bprinth". The original library TR.a" and bridge library "bprinto" are linked (step 16) to produce binary 
"glouglou" with "PR.a" being hidden in the process. The binary "glouglou" and spy library "sprinto" are then linked (step 
1 7) to produce a new library "PR.a" (confusion with the original library file of the same name can be simply avoided by 
storing them in different directories). Finally, the new library "PR.a" is linked (step 18) to the user program "object" to 
produce the executable user program. 

From a comparison of Figures 2 and 5, it can be seen that the present invention provides tracing and/or monitoring, 
without requiring any change in the source code of the original library "print.c" or in the source code of the user appli- 
cation "main.c". This reduces the time necessary for development of new applications. The invention also provides a 
dynamic choice of the tracing or monitoring level, even when the compiled programs are running. Since the system is 
dynamic, performance degradations are reduced. 

Annexed to this present description is a more detailed version of the source code for the foregoing embodiment of 
the invention. This example is written in the C language and was developed on a HP-UX workstation function. 

The example comprises six parts, that is: 

code for the original library 

code for the bridge library 

code for the spy library 

code for the user application 

code for the scope program 

a script for activating these programs 

Each of the first four parts comprises a source code together with a script for producing the output of the part. 

The example provided in the annex is only intended to trace the interaction between the user application and the 
print library, Obviously, different user programs could be used, and the tracing could be completed, or replaced by the 
monitoring of computer parameters. 

In the examples given above, the computer parameters or indications regarding the conditions prevailing in the 
computer are stored in a file. Obviously, instead of "storing" these indications in a file, one could "store" them by sending 
them to a display, where they would be displayed. 

It will be appreciated that although the above-described embodiment of the invention relates to tracing the interac- 
tion between a user application and a library, the invention can be applied to any interacting programs. It will further be 
appreciated that more than one instance of the final executable program may be simultaneously run (such an instance 
being generally referred to as a process). 



EP0801 348 A1 



ANNEX 1 

This Annex 1 relates to the original library. In the example, it comprises only a PRINT 
routine. "Print.c* is the- C language code for the library. "Print.h" holds the function 
prototype for PRINT and 'go* is the script for compiling print.c with print.h and 
creating a binary library PR.a. 



print . c 

# include <print.h> 

void PRINT (int number) 
{ 

printf ("This is the lib (%d) \n" , number) ; 

return; * 

} 



25 

print . h 

extern void PRINT (int) ; 

30 

cc -Aa -I. print.c -c print. o 
35 ar cr PR.a print. o 



40 



45 



so 
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ANNEX 2 

This Annex 2 relates to the bridge library, "hprint.c" is the C-language source code for 
the library and "bprinLh" holds the function prototype for function BPRINT. "go" is 
the script for compiling bprint.c, with printh and bprint.h to create an object bridge 
library "bprint.o"; "brpint.o" is linked to tt PR.a" so as to create an intermediary library 
"glougloiT, while hiding the PRINT routine. Thus, there is provided through 
"glouglou" a call to the original library routine PRINT, but this library routine is 
hidden in "glouglou", and only BPRINT can be called from externally of "glouglou". 

bprint - c 

# include <bprint-h> 
# include <print.h> 

void BPRINT (int number) 
{ 

printf ("This is the bridge (%d) \n" , number) ; 

PRINT (number) ; 

return; 

} 



bprint . h 



extern void BPRINT ( int ) ; 



go 

cc -Aa -I. -I../olib bprint.c -c bprint. o 

ar -x ../olib/PR.a 

Id -r -h PRINT * . o -o glouglou 
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ANNEX 3 

This Annex 3 relates to the spy library. " sprintx" is the C-language source code for 
the library. In this example, the spy library provides tracing of the interaction between 
the user application and the print library; the spy library first checks the tracing level, 
and writes the results of the tracing in a trace file called "/tmp/spy Trace w . In the 
example, for the sake of simplicity, only very simple tracing levels are provided, as 
explained below when describing annex 5. After having traced the interaction, the spy 
library calls BPRINT: thus, the spy library logs the function call it receives to the 
bridge library, where it is ultimately passed to the original print library. "sprint.1T 
holds the function prototype for the routine PRINT, "go" is the script for compiling 
sprintx with print. h and bprint.h to create an object spy library sprint.o; sprint.o is 
linked to glouglou, so as to create a library PR.a. The name of the library is the same 
as the original library, so that the user application will transparently use the assembly 
of the original library with the bridge library and the spy library. 



sprint . c 



# include <bprint.h> 
# include <print.h> 
# include <stdio.h> 
# include <sys/time.h> 
iinclude <sys/ipc.h> 
# include <sys/types .h> 
#include <sys/shm.h> 
iinclude < . . /scope/ scope .h> 

int errno; 

int level = TL_TRACE_FOT_SET; 

char *ptr; 

key_t key; 

FILE * out,* file; 



EP0 801 348 A1 



ANNEX 3 ....continued 



void set_trace_level { ) 

{ < 

int shmem, value, i; 

/* Scan if tfacelevel should be changed */ 
if (level == TL_TRACE_JJOT_SET ) 
{ ' 
printf ("Init tracing level \n*); 
out = fopen(Vt^^p/spyTrace , ' , *a"); 
if ( (int) out != 0 ) 
{ 

fprintf (out, - \n\t\tStarting. . . \n\t\t**** *******\n* ) 
} 

fflush(out) ; 

file = fopen(IFILE,"a*); 
if ( (int) file ==0) 

printf ("Can' t open file (%d) \u m ,errno) ; 

key « ft ok (I FILE, XD) ; 
if (key -= (key_t) -1) 

printf ("Can* t get key (%d) \n" ,errno) ; 

shmem = shmgett key, 0,0); 
ptr = shmat (shmem, 0, 0) ; 
} 

level = *ptr; 



void PRINT (int number) 
{ 

set_trace_level ( ) ; 

'/* printf ("macro results : %d %d\n" ,M_TRACE_FUNCTION,M_TRACE_P7^RAMS) ; */ 
if M_TRACE_FUNCTION 

fprintf (out, "This is the spy : function PRINTXn" ) ; 
if M_TRACE_PARAMS 

f printf (out, "This is the spy : number is %d\n* , number ) ; 

fflush(out) ,- 
_BPRINT( number) ; 
return; 
} 



go 

cc -Aa -I../olib -T../blib -D_INCLUDE_POSIX_SOURCE -D_INCLUDE_XOPEN_SOURCE sprin 
c -c sprint. o 

Id -r . . /blib/glouglou sprint. o -o both2.o.tmp 
rov both2.o..tmp both2.o 
ar cr PR. a both2.o 
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ANNEX 4 

This Annex 4 relates to the user application, "mainx" is the C-language source code 
for the application, and is mainly intended to print the sentence "On y va\ "go" is the 
script for compiling main.c to create main and an instrumented version of main called 
imain; these use the library "PR.a" created as explained in Annex 3. 



main.c 



#include <print.h> 

main() 
{ 

int i; 

printf (~On y va!\n") ; 
while (1 ) 
{ 

getchar ( ) ; 
PRINT (2) ; 
} 

} 



go 

echo "Making main" 

cc -g -Aa -I../olib main.c ../olib/PR.a -o main 
echo "Making imain" 

cc -g -Aa -I../olib main.c . ./slib/PR.a -o" imain 
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ANNEX 5 

This Annex 5 relates to the 'scope* program for dynamic change of the tracing level, 
"scopcc" is the C-language source code for the program. Only three tracing levels are 
provided in this example, that is, no tracing (level 1), tracing function calls (level 2) 
or tracing function parameters (level 4). Other tracing levels could be added. " scope. h" 
holds the function prototype, "go" is the script for compiling scope. c to create the 
scope interprocess function. 

scope. c 



•include <stdio.h> 
# include <sys/time.h> 
# include <sys/ipc.h> 
# include < sys/ types. h> 
# include <sys/shm.h> 
# include " scope. h" 

int errno; 

FILE * out=0; 

trace_l evel_t leve 1 =TL_TRACE_NOT_SET ; 



main ( ) 
{ 

key_t key; 
FILE * file; 
int shmem, level , i ; 
char *ptr; 

if <out = fopen( Vtrop/spyTrace* , "a" ) ) 
< 

level = TL_NO_TRACE; 

fprintf (out, " \n\t\ tS tar ting. . . \n\t\t**** 

} 

printf { "starting scope ! \n" ); 

file = fopen(IFILE, "a") ; 
if ( file « -1) 

printf ( 'Can' t open file (%d) \n" ,errno) ; 

key = ftok(IFILE,ID) ; 
if (key « (key_t) -1) 
{ 

printf ("Can* t get key (%d) \n* , errno) ; 

return (-1) ; 

) 

shmein=shmget(key,10,IPC_CREAT|IPC_EXCL|0666) ; 
if (shmem == -1) 
{ 

printf Cpb, petit pb \n - ); 

return(-l); 
) 

ptr = shmat (shmem, 0, 0) ; 

*ptr = TL_NO_TOACE; 

printf ( •Ready to trace\n* ) ; 



*\n-); 



continued 
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ANNEX 5 continued 



while (1) 
{ 

printfCl : NO TRACING , 2: FUNCTION , 4: PARAMETERS \n" ) ; 

print f ("Which tracing level ? >"); 

scanf <"%d",&i) ; 

print f ('Setting to %d \n",i); 

*ptr = i ; 

) 

} 



15 



scope , h 



#define SET_TRACE_LEVEL set_trace_level (■) 
#define OUT f print f (out, 

#define IFILE " /tmp/cntllpcF" 
#define ID 0x77 



25 



typedef enum{ 



30 



TL_TRACE_NOT_SET = 
TL_NO_TRACE 
TL_TRACE_FUNCTION= 
TL_TRACE_PARAMS = 
TL.TRACEL.RESULT = 
TL_TRACE^ALL 
TL_TRACE_DEBUG = 



0x000, 
0x001, 
0x002, 
0x004, 
0x080, 
OxOff , 

Oxlf f } trace_level_t ; 



# define M_TRACE — FUNCTION (level & TL_TRACE_FUNCTION) 
idefine M_TRACE_PARAMS (level & TL_TRACE_PARAMS } 



35 



40 



45 



go 

f reesm 

echo "Making le scope" 

cc -g -Aa -D_INCLUDE_POSIX_SOURCE -D_INCLUDE_XOPEN_SOURCE scope. c -o scope 



50 

note 



the f reesm command is used to free shared memory segments 
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ANNEX 6 

This Annex 6 relates to the script for activating the complete application, and running 
the user application. 



lets 

#!/bin/ksh 
set -x 

DIRS="olib blib slib scope prog " 

for dir in $DIRS 
do 

cd /users /pierres /pat/ spy/ $dir 
echo "executing go in $dir" 
go ' 
cd . . 
done 

cd /users/pierres /pat/spy 
f reesm 

hptena -e tail -f /tmp/spyTrace & 
hpterm -e scope/ scope & 
hpterin -e prog/imain & 



Claims 

1 . A method of automatically storing indications regarding conditions prevailing in a computer running a first program 

(1) that makes use of a second program (2), said method involving carrying out the following steps using an inter- 
face component (3): 

» receiving from the first program (1 ) messages destined for the second program (2), 

- passing said messages to the second program (2), and 

■- monitoring and storing indications regarding conditions prevailing in the computer at the time the messages 
are received or passed. 

2. A method according to claim 1 , wherein said interface component (3) receives messages from the second program 

(2) destined for the first program (1) and passes them to the first program (1). 

3. A method according to claim 1 or 2, including the step of providing said interface component (3) by: 

» providing a bridge program allowing use of said second program (2) whilst hiding it from said first program 
(1): 

- providing a spy program for monitoring and storing said indications, for receiving said messages from the first 
program (1), and for passing these messages to the bridge program. 

4. A method according to claim 3, wherein the spy program has at least one routine with the same name as a routine 
of said second program (2). 
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5. A method according to claim 3, wherein said step of providing the interface component further involves: 

-- linking an object version of said bridge program with a compiled version of said second program to produce 
an intermediate program; 

- linking an object version of said spy program with the intermediate program to produce a further program 
having the name and functionalities of said second program, but allowing monitoring and storing of said indi- 
cations; and 

- linking a compiled version of said user application with said further program. 

6. A method according to one of claims 1 to 5, further comprising the step of providing a control program for dynami- 
cally changing the indications monitored and stored. 

7. A method according to claim 6, comprising the steps of using said control program to set a parameter in a memory 
area accessible to said interface component, and accessing said parameter with said interface component and 
determining the indications to be monitored and stored in dependence on the value of said parameter. 

8. A method according to claim 7, wherein said parameter is accessed by said interface component each time it 
receives/passes said messages. 

9. A method according to claim 1, wherein said second program is a library of routines at least one of which is used 
by said first program. 

1 0. A method according to claim 1 , wherein said indications regarding conditions prevailing in the computer, comprise 
indications of the function calls made by the first program. 
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